Specifications , Refinements , and Atomic Registers

Sequential programs and algorithms are usually specified by means of preconditions and postconditions. This is not possible for concurrent and reactive programs, since their behaviour during execution is more interesting than their final states, even when termination is desirable. There are two schools in the way behaviours of concurrent and reactive programs are described. In the process algebra school of Milner [Mil80] and Hoare [Hoa85], the behaviours are characterized as sequences of transitions. This is good for communication protocols, but less well-suited for algorithms with complicated states and state transitions. In this note, we follow the school of Abadi, Lamport [AL91,Lam94], Manna and Pnueli [MP92,MP95], in which behaviours are characterized as (infinite) sequences of states. The idea of refinement calculus is to treat specifications, algorithms and programs under the same heading, viz. as specifications of behaviours, the main difference being that programs are closer to executable code than general specifications. Since the whole state contains variables that are not interesting for the specification, we have to be explicit about the variables relevant for the specification. These are called the visible variables. The combination of all visible variables is the visible state. In this way, we also get visible behaviours: infinite sequences of visible states. One specification implements another if and only if all visible behaviours of the first specification are also visible behaviours of the second specification. Although they may change roles, we refer to the implementing specification as the concrete one, and to the implemented specification as the abstract one. Arguing about behaviours of a given specification is very inconvenient and error prone. This is the reason that methods have been developed to prove implementation relations, in which consideration of the behaviours is eliminated as much as possible. These methods are based on concepts like invariants and simulation. In Section 2, we define specifications and their sets of (visible) behaviours.